AMOS PD CD/amospdcd.iso/aminet/amoslist0993.lzh/AMOSLIST2/[e-mail]_Wed Sep 1 22:11:25 1993.msg

Internet Message Format | 1993-09-03 | 5KB

Received: from nextsun.INS.CWRU.Edu by access.digex.net with SMTP id AB01994
  (5.65c/IDA-1.4.4 for <[e-mail]>); Wed, 1 Sep 1993 22:11:20 -0400
Received: from svcs1.digex.net by nextsun.INS.CWRU.Edu with SMTP (5.65b+ida+/CWRU-1.5.2-freenet-gw)
    id AA29152; Wed, 1 Sep 93 22:11:00 -0400 (from [e-mail] for [e-mail])
Received: by svcs1.digex.net id AA16173
  (5.65c/IDA-1.4.4 for amos-list-out); Wed, 1 Sep 1993 22:00:39 -0400
Received: from access.digex.net by svcs1.digex.net with SMTP id AA16164
  (5.65c/IDA-1.4.4 for <[e-mail]>); Wed, 1 Sep 1993 22:00:34 -0400
Received: from wraith.cs.uow.edu.au by access.digex.net with SMTP id AA29666
  (5.65c/IDA-1.4.4 for <[e-mail]>); Wed, 1 Sep 1993 22:00:16 -0400
Received: from topaz.cs.uow.edu.au by wraith.cs.uow.edu.au with SMTP
    (5.65c/IDA-1.4.4); id AA01426; Thu, 2 Sep 1993 11:59:57 +1000
    (from [e-mail] for <[e-mail]>)
Received: by topaz.cs.uow.edu.au id AA26152
  (5.65c/IDA-CLIENT for [e-mail]); Thu, 2 Sep 1993 11:59:55 +1000
From: Richard Barry Ling <[e-mail]>
Message-Id: <[e-mail]>
Subject: Re: Jumping/flicker
To: [e-mail] (AMOS User group)
Date: Thu, 2 Sep 1993 11:59:54 +1000 (EST)
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Content-Length: 3203
Status: RO


 From: Tom Plackowski <[e-mail]>

> Ok! This is useful information!
> So screen swap really means, "Swap Screen AT next VBL". (Or is that DURING, or
> AFTER?)

It's not really important; it happens some time after one scan drops off the
bottom of the screen, and some time before the next one starts at the top,
when there is no display output.  I have found by experiment that it happens
just before the new frame begins at the top of the screen.  IMO it would be
better if it happened as early as possible, so you get maximum drawing time
during VBL, but this would have been a little harder on Francois.  I think
that AMOS uses the system's VBL interrupt, which means the exact time when
VBL occurs would vary depending on the number of interrupt handlers running.

> In fact, it sounds CRUCIAL to have the Screen Swap BEFORE the Wait Vbl.

It is.  I can't see how having them the other way round can get useful
results, though I expect it could be good for something.  Winning the
"flicker of the century award" perhaps? :)

>
> You might like to fill me in on the low level mechanism of the graphics/copper
> stuff.
>
> Correct this please:
>     1) Screen Swap adjusts pointers in Screen Base

Screen swap is just a change of pointers... I haven't looked in screen base
but assume they're there..

>     1a) New copper list is created? Old one modified?

Shouldn't be.  The copper lists for both frames are generated in advance,
all that should happen is the pointer to the current one is changed (unless
you open or close screens, move entire screens around or otherwise change
the display, this may cause a complete reconstruction of the copper lists.)

>     2) Video stuff is already committed to display the frame from the
>        original pointers, and continues to do so

Yup.  At the start of a frame, the copper starts thru the copper list which
is pointed to at that instant, and it will stick with it until the end of
the frame, no matter what AMOS commands you do - short of directly poking
the copper registers mid-frame, of course (generally a bad idea. ;-))

>     3) At VBL the different set of copper instructions directs display to
>        come from the new bitplanes

Yep.  (Provided there's other bitplanes out there to display, of course!  If
your screen isn't double-buffered, then you don't get a change.  And if you
have disabled automatic screen swapping, you have to call Screen Swap, which
will take effect next frame.)

>
> And anyhow: How do you know these things? Have you looked at the AMOS source?
> Is this just conjecture as to how it should be done? How you would do it? The
> only way possible?

The manual gives a bit of insight into the inner workings of AMOS, but it's
mostly gobbeldigook unless you know a bit about the hardware.  I have the
Amiga HWRM which helps with the jargon like vertical blanking interrupts,
blitter minterms, and bitplane control register BPLCON0.  :-)

>
> // Tom
>

RL.

This has been a dinosaur-free announcement.

==========================  Generating: .signature
   Richard Ling             - colour analysis... complete
 [e-mail]     - clipping... complete
==========================  - rendering... 37.6%